C.S.M.P. Digest             Fri, 05 Feb 93       Volume 2 : Issue 9

Today's Topics:

	TCL, CPanes of variant shapes?
	how do you do automated GUI testing?
	Curves in QuickDraw GX



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, there is
no way that I know of for you to post articles to the group.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to LISTSERV@ricevm1.rice.edu for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to mkelly@cs.uoregon.edu, and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to mkelly@cs.uoregon.edu.


-------------------------------------------------------

From: urban@yoda.fsl.noaa.gov (Art Urban)
Subject: TCL, CPanes of variant shapes?
Organization: Forecast Systems Lab, NOAA, Boulder CO, USA
Date: Sun, 3 Jan 1993 21:37:13 GMT

Well, the subject line almost states the question well enough...but,

Can I make a CPane subclass which is a *region* and not a rectangle?

I would love to have a hex shaped region for trapping GoodClicks and
such, without having overlapping panes. I see problems handling overlapping
rectangles which contain "drawn" hexes which must abutt each other.

- -- 
Art Urban 					        urban@yoda.fsl.noaa.gov
===============================================================================
 "Look, he's being attacked by creamy nugget centers."		 	 -Joel
===============================================================================

+++++++++++++++++++++++++++

From: jimlynch@netcom.com (Jim Lynch)
Date: 4 Jan 93 23:01:14 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

Yes, you can. Here's mine. Feel free to have it as a toy, but if you
distribute it, it must include this message. Don't use it in
commercially available software without talking to me well in advance.
 
- --------------- *** file CRegion.c *** ------------------
#include "CRegion.h"
 
void CRegion::IRegion
(
        CView                   *anEnclosure,
        CBureaucrat             *aSupervisor,
        short                   aWidth,
        short                   aHeight,
        short                   aHEncl,
        short                   aVEncl,
        SizingOption    aHSizing,
        SizingOption    aVSizing
)
{
        inherited::IPane
        (
                anEnclosure, aSupervisor,
                aWidth, aHeight,
                aHEncl, aVEncl,
                aHSizing, aVSizing
        ) ;
 
        itsRegionH = NewRgn() ;
}
 
void CRegion::Dispose(void)
}
        return(result) ;
        }
                result = PtInRgn(thePoint, itsRegionH) ;
                thePoint.v = theLPoint.v ;
                thePoint.h = theLPoint.h ;
                WindToFrame(thePoint, &theLPoint) ;
        {
                aWidth, aHeight,
                aHEncl, aVEncl,
                aHSizing, aVSizing
        ) ;
 
        itsRegionH = NewRgn() ;
}
 
void CRegion::Dispose(void)
{
        DisposeRgn(itsRegionH) ;
 
        inherited::Dispose() ;
}
 
Boolean CRegion::Contains(Point thePoint)
{
        LongPt theLPoint ;
        Boolean result ;
 
        result = FALSE ;
 
        if(ReallyVisible())
        {
                WindToFrame(thePoint, &theLPoint) ;
                thePoint.h = theLPoint.h ;
                thePoint.v = theLPoint.v ;
                result = PtInRgn(thePoint, itsRegionH) ;
        }
 
        return(result) ;
}
 
- -------------- *** end of CRegion.c *** ------------------
 
Here's the .h file:
 
- --------------- *** CRegion.h *** --------------------
#pragma once
 
#include <CPane.h>
 
class CRegion : public CPane
{
protected:
        RgnHandle itsRegionH ;
 
public:
        void IRegion
        (
                CView                   *anEnclosure,
                CBureaucrat             *aSupervisor,
                short                   aWidth,
                short                   aHeight,
                short                   aHEncl,
                short                   aVEncl,
                SizingOption    aHSizing,
                SizingOption    aVSizing
        ) ;
        void Dispose(void) ;
 
        Boolean Contains(Point thePoint);
} ;
 
- ---------------- *** end of CRegion.h *** ------------
 
Notice I don't do anything to itsRegionH after allocating; that's up to your
code. Also note that I override CPane::Contains() so CRegion's version checks
to see if the point lies in the region referred to by itsRegionH.
 
I use this as an abstract class. I was doing something with piano keys which
are irregular shapes. Made buttons out of them, as I recall... In any case,
my CKey::IKey method called its superclass' IRegion method then did something
to the region (like make a shape).
 
So you could make a CHex which is a subclass of CRegion and draw a hex polygon
in itsRegionH...

---------------------------

From: bagwill@swe.ncsl.nist.gov (Bob Bagwill)
Subject: how do you do automated GUI testing?
Date: 4 Jan 93 15:51:25 GMT

How does Apple (if they choose to respond) do automated testing
of the GUI aspect of their product?

How do "professional" Mac developers do automated testing of
their products?

I will summarize responses (if any).  If anyone is willing to
share information with me, but don't want it shared with the
net, put "PRIVATE" at the head of your response.

Warning: Don't send anything your lawyers don't want you to share.  And
remember that Internet email is not secure.

- --
Bob Bagwill
bagwill@swe.ncsl.nist.gov
NIST/Computer Systems Lab/Distributed Systems Engineering Group

+++++++++++++++++++++++++++

From: d88-jwa@dront.nada.kth.se (Jon Wtte)
Date: 4 Jan 93 20:51:27 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <7750@dove.nist.gov> bagwill@swe.ncsl.nist.gov (Bob Bagwill) writes:

>How does Apple (if they choose to respond) do automated testing
>of the GUI aspect of their product?

>How do "professional" Mac developers do automated testing of
>their products?

Apple has a very good product called Virtual User that lets
you create customized or random sessions and play them back
over a network to a lot of macs at the same time.

It's good, and I haven't seen anything better on any other
platform. I seem to remember the arrangements about it being
very inexpensive too.

>Warning: Don't send anything your lawyers don't want you to share.  And
>remember that Internet email is not secure.

Huh? Why would anyone NOT remember that? It's a fact of
life and has always been.

Now, phone lines (cellular phones especially) are not
secure EITHER, and that's something people tend to forget.


- -- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --

   Speed is arbitrary. Don't believe me? Try a PowerBook 180 running
   System 7 against a 486 laptop running Windows 3.1.

+++++++++++++++++++++++++++

From: howard@netcom.com (Howard Berkey)
Date: 4 Jan 93 22:29:55 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <1993Jan4.205127.25229@kth.se> d88-jwa@dront.nada.kth.se (Jon Wtte) writes:
>In <7750@dove.nist.gov> bagwill@swe.ncsl.nist.gov (Bob Bagwill) writes:
>
>>How does Apple (if they choose to respond) do automated testing
>>of the GUI aspect of their product?
>
>>How do "professional" Mac developers do automated testing of
>>their products?
>
>Apple has a very good product called Virtual User that lets
>you create customized or random sessions and play them back
>over a network to a lot of macs at the same time.
>
>It's good, and I haven't seen anything better on any other
>platform. I seem to remember the arrangements about it being
>very inexpensive too.
>

You can say that again.  Similar tools for the PC are ~3-500 dollars,
and x-based tools start around $3-15,000.  (They do more though.  Not an
order of magnitude more, however.)  VU is supposedly a good package.

- -Howard

- -- 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard "Pasty-faced" Berkey                       	   howard@netcom.com
		    I just don't want to know, anymore.
... .. ...   ... .. ...   ... .. ...    ... .. ...   ... .. ...   ... .. ...

---------------------------

From: lari@strauss.cs.unc.edu (Humayun Lari)
Subject: Curves in QuickDraw GX
Date: 14 Dec 92 02:45:27 GMT


Hi, all. Yes, I have finals starting tomorrow, but there's one little question
I just *have* to ask... :-)

Fact: QuickDraw GX is going to use quadratic bezier curves a la TrueType.

However: editing quadratic curves is somewhat painful compared to editing
PostScript cubic curves, because of the number of extra points required to
describe similar contours.

So: are we going to see lots of GX programs that <ouch> make us use quadratic
curves to describe shapes? Or <grin> is there some magic way to display cubic
curves using quadratics? As far as I know, there's no simple way of doing so.
Does <gasp> GX provide some way of performing this magic? If not <"display
ignorance" mode on>, shouldn't it?

I guess what I'm worried about is programs showing up that make editing curves
harder than it needs to be -- much like the spline curves in MacDraw...

Stressfully yours,

Humayun Lari
(lari@cs.unc.edu)

P.S. Personally, I *still* think NuGraph sounds a little cooler than "QuickDraw
GX"... of course, average users might think it was a charting package...

+++++++++++++++++++++++++++

From: bayes@hplvec.LVLD.HP.COM (Scott Bayes)
Date: Thu, 17 Dec 1992 00:00:08 GMT
Organization: Hewlett-Packard Co., Loveland, CO

> So: are we going to see lots of GX programs that <ouch> make us use quadratic
> curves to describe shapes? Or <grin> is there some magic way to display cubic
> curves using quadratics? As far as I know, there's no simple way of doing so.
> Does <gasp> GX provide some way of performing this magic? If not <"display
> ignorance" mode on>, shouldn't it?

Quadratics and (non-degenerate) cubics can't even describe the same
curves.  It's hard to see how to do the "magic" without approximations
and lotsa MIPS, as you say.

ScottB

+++++++++++++++++++++++++++

From: perm@csd.uu.se (Per Mildner)
Date: 18 Dec 92 14:28:18
Organization: Computing Science Dept.,Uppsala University, Sweden


I seem to remember a question about this at the last WWDC. I think the
specific question was about outlining cubic curves requiring quadratic
curves, this was from someone who had implemented similar
functionality in a product. The answer was something like: "Yes,
normally, but we have some very bright math people", ie, they use some
sort of approximation magic.

- --
Per Mildner			perm@CSD.UU.SE
Computing Science Dept.		tel: +46 18181049
Uppsala University, Sweden	fax: +46 18521270

+++++++++++++++++++++++++++

From: bwilliam@iat.holonet.net (Bill Williams)
Organization: HoloNet National Internet Access BBS: 510-704-1058/modem
Date: Wed, 23 Dec 1992 06:12:38 GMT

>From the center of my handwritten notes regarding Quickdraw GX as presented
at Apples May 92 WWDC....
 
"The spline routines are used with inset and an outset values to create 
"fat" splines, the two outer edges are different splines (derivitive 
curves) that approach cubic order complexity, but are not, and can be
 converted back to the original very quickly (Rob Johnson, a math prof
 from UCLA invented fast transformation algorithms for all QD GX spline
 calculations, and is now an apple QD GX contributor)"
 
 
For those interested heres a bunch of my other observations as recorded that
week intact and without changes......
 
 
 
Beyond QuickDraw : the next generation in imaging
Given by Cary Clark - graphics team leader and author of color fonts, and
old 3D quickdraw.
 
The introduction of several discussions of Apples COMPLETE REPLACEMENT of
QuickDraw with a near clone of Adobe DisplayPostscript called QuickDraw
GX. Its code name was Skia ("Skee-ah"). It is a geometry (object) based
graphics model.
 
It is nearly finished and will be available three different ways (end user
$$, distributable license, and eventually free inclusion in a future
system release).
 
Wow, wow, wow. It is definitely NOT as fast as display postscript, but in
many ways it seemed faster. Work started in 1988 before DisplayPostscript
was shown publicly. It is of course completely device independent, and its
output files when printing, even after customization for a specific device
at spool initiation ARE DEVICE INDEPENDENT AT ALL TIMES. Final printed
output devices may be raster devices, vector devices (plotter) or
Postscript devices.
 
No words or tokens are used in the imaging model, there is no server
level, instead it appears as good-old-fashioned quickdraw to a normal
programmer except that all geometries are based on 32 bit values and
sometimes 64 bit values. (A fixed point is assumed when some values are used)
 
Unlike DisplayPostscript floating point values and computations are NOT
used. This is a negative trait. 
 
Also unlike postscript, YOU MAY NOT SEND CODE OF ANYKIND TO THE OUTPUT
SPOOLED IMAGE. Thus the author of "Jag" was told that his anti-aliasing
product has no value because the effects of his product EXCEPT AS DEVICE
DEPENDENT BITMAPS cannot be sent through the spooler and therefore should
not be integrated into QD GX. The reason: THE GOAL OF QD GX IS TO MATCH
THE SCREEN TO THE PRINTED OUTPUT. No code encapsulation is permitted. This
is a good intention, but not providing spoolable code (as with PostScript)
is a negative trait. 
 
Like DisplayPostscript, QD GX is a single pixel color model, and
anti-aliasing and ramping is not supported. This is not to be confused
with the pleasing types of blending fills that it does support.
 
 
You may mix Quickdraw commands interspersed with QuickDraw GX without too
much effort. Unfortunately, if you do, you must be careful to use a CASE
SENSITIVE LANGUAGE such as Modula-2, C, C++ because there is a RPointS and
a RpointS as well as QuickDraws RRectS and the new QuickDraw GXUs RrectS.
Though on one slide I saw the word RrectangleS instead of rect, so I
assume in Pascal they have a RgxPointS and a RrectangleS redefinition.
 
It does everything that display postscript does and a few extra things
(such as placing pictures at joins of two lines).
 
It has the AMAZING benefit of using the highly optimizable quadratic
spline for all curve and path operations. Though it cannot draw a circle.
(I am not joking, strictly speaking, MANY of QuickDraw GX primitives are
actually "libraries" outside of the lower lever QuickDraw GX.) I think
drawcircle is a library routine. The spline routines are used with inset
and an outset values to create "fat" splines, the two outer edges are
different splines (derivitive curves) that approach cubic order
complexity, but are not, and can be converted back to the original very
quickly (Rob Johnson, a math prof from UCLA invented fast transformation
algorithms for all QD GX spline calculations, and is now an apple QD GX
contributor)
 
I got the feeling that "shapes", not paths or spline derived curves, were
used for all of the very fast animated demos presented  (50 demos). I
believe that "shapes" do NOT possess splines but rather are decomposed
curves defined solely of small straight line segments. This is for speed
speed speed. The programmer gets to define the segmentation parameters used.
 
Shapes are defined by fixed point, to prevent degradation after any series
of permanent transformations.
 
The system supports a three-D transformation matrix with many library
routines to help set the matrix parameters. Two values in the Matrix are
unconventionally used for storage of variables meant for perspective
distortion. (QD GX has no three dimensional routines, and the
unconventional usage does not affect the non-existent "z" data)
It has tons of layered transformation matrices at many layers before the
final image is drawn and seems at most times to be a full blown 3D imaging
model... but it isn't.
 
The matrix routines support fast skew, distort, and rotation (including
bitmaps)
 
Patterns are now two parts, pattern data and "color shade" are separate
identities.
 
There are still no pixel locations in QuickDraw, points have always been
an abstraction and still are.... but programmers must be cautious to shift
all position info to convert all points into fixed point math to avoid
unwanted locations.
 
The new more accurate pixel locations allow much more exact vector line
rotation even on 72 point monitors. The effect needs to be dynamic to
discern the enhancement though.
 
It supports compressed "infinite-precision" BitMap regions, very nice
results were obtained in the demos.
 
TrueType and Adobe type 1 fonts (under ATM) are EXACTLY EQUAL in usage in
QD GX, neither has any preferential treatment in ANY WAY.
 
Font families have meaning now in the menu interface (like Adobe's Type
Reunion already does)
 
The new font support is almost as complete as postscripts with some
amazing differences. Primarily the ability to use different fancy fonts
based on the characters adjacent to the font. Some astoundingly beautiful
effects were shown with a slightly altered Zapf Chancery. Letters on the
ends of words had bold sweeping flourishes, and capital letters at the
beginning of words had long sweeping tails under the adjacent characters.
WOW. Apple said they are commissioning a company to create a special "Old
English" font for them.
 
A new Adobe Illustrator (version NIA 3.2) was shown that swapped back and
forth between QD and QD GX. It had a GODDAMN STUPID PREVIEW MODE as it
always has on systems that do not have built in display postscript,
because of the nature of the program. The absolute horrifying restriction
was only observed by me and other people that may have seen the
"No-preview-mode-crap" NeXT version of Adobe Illustrator. Man, what an
application not to show as a demo!
 
QD GX is a large set of different new technologies, especially for
printing. A kinder gentler series of major changes in printer interfaces
would make most people very happy. It is MUCH less cluttered, and far more
restricted without probing. A control panel much like system 6's "general"
is used to access third party extensions. In fact it is so simple a new
menu item is defined by apple called "Print One Copy". Note the lack of
"ellipses" (...). That's right it does what it says no questions asked.
The audience clapped.
 
A printer "Finder" was created to manage spooling. It has as many features
as the real finder in several ways. Plus it appears to be part of the
Finder. WOW.
 
Plotters are supported.
 
Hit detection for mouse clicks as well as animated object collision is a
major part of QD GX. Including accurate hit detection after all those
layers of skewing, distorting, rotating, etcetera.... WOW. This is even
better than the NeXT (one of the NeXT's few limitations from what I recall
is a "lighter" hit detection system.
 
Multiple color spaces are supported (even within one image!!!!!!!!!)
 
It supports all the cool stuff color Postscript (2) does for dithering,
screen rotation (arbitrary angles), etc. 
 
It supports viewports in a VERY ABSTRACT MANNER. a port can be a three-d
is view any where in a space and can be displayed in a arbitrary shaped
region anywhere on a device including MULTIPLE VIEWS OR THE SAME SCENE AT
THE SAME TIME. The multiple views can all have different color depths and
pixel resolutions, and dithering, and screening, and be somewhere on the
same device!
 
Unlike postscript it supports RTL LTR and vertical languages, unlike
Postscript it can be used to support indic and arabic languages where the
characters change dramatically based on there position and neighboring
glyphs. Arabic, Chinese and others where shown.
 
Like Postscript, the fonts can be filled, set on paths, stretched, etc.
etc. etc. Including bizarre text effects as seen with many Postscript
programs.
 
Users can specify weights directly in their applications (make it 10%
bolder, etc.)!
 
Oliver Steele wrote some AMAZING high speed graphics demos that showcased
QD GX and two of them,  "deflection angle" and "velocity lines" are
definite collector items.
 
Like postscript, a path drawing a line cannot be truly "dashed". Like
postscript the beginning and the ending of a path can have special
endcaps. Endcaps are allowed to be "negative" (erasing)
 
QD GX supports multiple monitors. Apple acknowledged that Radius invented
multiple monitor drawing first, not them or anyone else in the industry.
 
You cannot crash QDGX when its many many debugging options are enabled. 
 
QD GX uses ZERO BYTES OF APPLICATION HEAP and stores all its structures in
its own very special heap structures. It uses almost no Macintosh
routines. It does not ever use the memory manager. It cannot run out of
memory if disk space is available.
 
Disk is used as memory FOR ANY AND ALL OPERATIONS! QDGX can work on
immense bitmaps, far larger than supportable in RAM. Sadly, Cary Clark
calls this "backing store" instead of "virtual memory" because he likes
anal retentive 1967 IBM mainframe buzzwords.
 
QD GX has a special debugger, BUT THEY WERE NOT ALLOWED TO SHOW IT. Odd.
very odd.
 
No recalculations are made in QD GX, it has lots of optimization
strategies of all kinds (as does display postscript) but unlike its
competitor, it can warn the user if wasteful code is being generated. Plus
it never calculates any intermediate variable that is not eventually
actually needed! If true I am impressed! It would be almost psychic-ware.
 
It runs (theoretically) in system 6, but needs 7.0 for printing of any kind.
 
The famous QD pattern scrolling bug (user preference?) is now selectable
by programmer, patterns can be fixed or positional.
 
No assembly (very little) is used. Because they are greedy opportunistic
pigs that are thinking of saving time porting it again and again
naturally, but I feel that when 250,000 Motorola boxes from Apple ship per
month they can afford to hire a few real programmers. GEEZ! Never in my
life have I heard someone brag that almost none of their GRAPHICS ROUTINES
are written in assembly.
 
 
MAJOR LIMITATION: all views and bitmaps based on pixels can have more than
32K pixels per square side. EVER. But amazingly, QD GX will "butt-end"
giant bitmaps through the system and accurately align and join them (even
through translation, and distortion) so that you can extract and
manipulate portions of them. In effect an INFINITE SIZED bitmap can be
processed. (A satellite imaging company in the audience asked the question
because all their photos have more than 32,000 pixels per side!)
 
Source code was handed out. An unprecedented amount of libraries and
source code will be available before and after QD GX's debut.
 
============================================================
 
 
Whew! I have countless other pages of opinions and rambling drivel
covering many other sessions at the WWDC written in the same manner if
anyone is interested in my remarks on other Apple technologies.

Bill Williams (NOT familiar with QuickDraw GX yet)



+++++++++++++++++++++++++++

From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Date: 24 Dec 92 13:13:41 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <Bzp7x4.90D@iat.holonet.net>, bwilliam@iat.holonet.net
(Bill Williams) posts his thoroughly fascinating notes on QuickDraw GX.
Thanks Bill! There's a place for your posting in my archive of USENET snippets.

> Wow, wow, wow. It is definitely NOT as fast as display postscript, but in
> many ways it seemed faster.

That's a little worrying, considering the sort of hardware it seems to take
to run Display PostScript (eg 68040-based NeXTs). Will QuickDraw GX not
run on 68000 CPUs?

> No words or tokens are used in the imaging model,

Well, there'll be another lot of extensions to the QuickDraw picture format,
won't there?

> there is no server level

No big loss. Having one X Window System is bad enough. :-)

> Like DisplayPostscript, QD GX is a single pixel color model, and
> anti-aliasing and ramping is not supported.

You can use the existing anti-aliasing capabilities of Color QuickDraw,
can't you?

> You may mix Quickdraw commands interspersed with QuickDraw GX without too
> much effort. Unfortunately, if you do, you must be careful to use a CASE
> SENSITIVE LANGUAGE such as Modula-2, C, C++ because there is a RPointS and
> a RpointS as well as QuickDraws RRectS and the new QuickDraw GXUs RrectS.
> Though on one slide I saw the word RrectangleS instead of rect, so I
> assume in Pascal they have a RgxPointS and a RrectangleS redefinition.

Another option is to use a language with scope control, eg "OldQuickDraw.Point"
versus "QuickDrawGX.Point". Modula-2 allows you to do this. But of course,
language vendors will hack the interfaces to suit themselves. :-)

> Shapes are defined by fixed point, to prevent degradation after any series
> of permanent transformations.

You'll get rounding errors, though. Does QuickDraw GX support "CORDIC"
transformations? I think these are a representation of trig functions that
allow you to do endlessly-repeated rotational transformations with zero rounding
error.

> The new font support is almost as complete as postscripts with some
> amazing differences. Primarily the ability to use different fancy fonts
> based on the characters adjacent to the font. Some astoundingly beautiful
> effects were shown with a slightly altered Zapf Chancery. Letters on the
> ends of words had bold sweeping flourishes, and capital letters at the
> beginning of words had long sweeping tails under the adjacent characters.
> WOW. Apple said they are commissioning a company to create a special "Old
> English" font for them.

Ah, the legendary "Line Layout Manager"! I saw a demo of this way back in
1988 (?), back when it was part of the promised feature set for System 7.
The ligatures would appear and disappear as you were typing and deleting
characters. I'm drooling just thinking about it...

> The famous QD pattern scrolling bug (user preference?) is now selectable
> by programmer, patterns can be fixed or positional.

Is this the one where patterns are normally aligned to (0,0) in the coordinate
space? You could always change that, it just wasn't very well explained how to
do it. :-)

Lawrence D'Oliveiro                       fone: +64-7-856-2889
Computer Services Dept                     fax: +64-7-838-4066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
At first all I could do, in fact, was what I've been doing since the age of
seven when any disaster has struck: ask myself how Batman would have acted
in similar circumstances.                                -- PCW Oct '92

+++++++++++++++++++++++++++

From: d88-jwa@dront.nada.kth.se (Jon Wtte)
Date: 24 Dec 92 23:47:52 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <1992Dec24.131341.12976@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

>That's a little worrying, considering the sort of hardware it seems to take
>to run Display PostScript (eg 68040-based NeXTs). Will QuickDraw GX not
>run on 68000 CPUs?

The 68000 is dead, buried and forgotten. Except the PB100 is
still the lightest PowerBook around. The screen on the Duos
sucks whole mountains.

>> No words or tokens are used in the imaging model,

>Well, there'll be another lot of extensions to the QuickDraw picture format,
>won't there?

QuickDraw GX is orthogonal from QuickDraw. It will co-exist, but
QuickDraw will not be extended to know anything about GX. At
least that's my impressino.

- -- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --

   There's no problem that can't be solved using brute-force algorithms
   and a sufficiently fast computer. Ergo, buy more hardware.

+++++++++++++++++++++++++++

From: ksand@apple.com (Kent Sandvik )
Date: 30 Dec 92 22:13:09 GMT
Organization: (Evil Eye Creature from Mars, Inc.)

In article <Bzp7x4.90D@iat.holonet.net>, bwilliam@iat.holonet.net (Bill
Williams) wrote:
> No assembly (very little) is used. Because they are greedy opportunistic
> pigs that are thinking of saving time porting it again and again
> naturally, but I feel that when 250,000 Motorola boxes from Apple ship per
> month they can afford to hire a few real programmers. GEEZ! Never in my
> life have I heard someone brag that almost none of their GRAPHICS ROUTINES
> are written in assembly.

Well, concerning a PowerPC port it makes sense, because asm is no-no
or 'if-you-really-need-it' option on this platform.
 
Kent
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000

+++++++++++++++++++++++++++

From: russotto@eng.umd.edu (Matthew T. Russotto)
Date: 31 Dec 92 22:49:23 GMT
Organization: Project GLUE, University of Maryland, College Park

In article <ksand-301292141154@wintermute.apple.com> ksand@apple.com (Kent Sandvik ) writes:
>
>Well, concerning a PowerPC port it makes sense, because asm is no-no
>or 'if-you-really-need-it' option on this platform.

Uhhh.... why?

- -- 
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: k044477@hobbes.kzoo.edu (Jamie R. McCarthy)
Date: 1 Jan 93 01:26:08 GMT
Organization: Kalamazoo College

russotto@eng.umd.edu (Matthew T. Russotto) writes:
>ksand@apple.com (Kent Sandvik ) writes:
>>
>>[Why is QuickDraw GX written entirely in C?]
>>Well, concerning a PowerPC port it makes sense, because asm is no-no
>>or 'if-you-really-need-it' option on this platform.
>
>Uhhh.... why?

Because the PowerPC will run on a different processor, and the Toolbox
will be written in the native code for that processor.  If Apple writes
it in assembly, they have to write it (and debug it) twice.
- -- 
 Jamie McCarthy      Internet: k044477@kzoo.edu      AppleLink: j.mccarthy
 "A degree in Computer Science from Berkeley didn't much qualify me to uphold
  the banner of Chaos against the forces of Order."              - R. Zelazny

+++++++++++++++++++++++++++

From: werner@dewey.soe.berkeley.edu (John Werner)
Date: 1 Jan 93 01:55:32 GMT
Organization: School of Education, U.C. Berkeley

In article <1993Jan1.012608.5403@hobbes.kzoo.edu> k044477@hobbes.kzoo.edu (Jamie R. McCarthy) writes:
>Because the PowerPC will run on a different processor, and the Toolbox
>will be written in the native code for that processor.  If Apple writes
>it in assembly, they have to write it (and debug it) twice.

Also, hand-coding something in assembler for a RISC chip is MUCH
harder than on a traditional processor.  There's a smaller instruction
set, more registers, and you have to worry about pipelining.  A good
optimizing compiler can usually do a better job than most humans can
do (at least in a reasonable amount of time).
- -- 
John Werner                        werner@soe.berkeley.edu
UC Berkeley School of Education    

+++++++++++++++++++++++++++

From: sunilg@access.digex.com (Sunil Gupta)
Date: 1 Jan 93 17:26:14 GMT
Organization: Express Access Online Communications, Greenbelt, MD USA

werner@dewey.soe.berkeley.edu (John Werner) writes:
: 
: Also, hand-coding something in assembler for a RISC chip is MUCH
: harder than on a traditional processor.  There's a smaller instruction
: set, more registers, and you have to worry about pipelining.  A good
: optimizing compiler can usually do a better job than most humans can
: do (at least in a reasonable amount of time).

Your comment is true for RISC processors, but the complaint was being
made about the CISC implementation. My small (4 person) programming shop
maintains our code for a number of platforms. For CISC implementations
we usually tune critical sections in assembly and usually let the
compiler worry about that for RISC implementations. If we can do that,
I'm sure that a megabucks company can spare a few programmers for a
project that would greatly enhance their products.

Sunil Gupta
Monsoon Software, Inc.
sg@monsoon.com

+++++++++++++++++++++++++++

From: jmunkki@vipunen.hut.fi (Juri Munkki)
Date: 1 Jan 93 18:34:51 GMT
Organization: Helsinki University of Technology

In article <1i1urmINNt8g@mirror.digex.com> sunilg@access.digex.com (Sunil Gupta) writes:
>werner@dewey.soe.berkeley.edu (John Werner) writes:
>: Also, hand-coding something in assembler for a RISC chip is MUCH
>: harder than on a traditional processor.  There's a smaller instruction
>: set, more registers, and you have to worry about pipelining.  A good
>: optimizing compiler can usually do a better job than most humans can
>: do (at least in a reasonable amount of time).
>
>Your comment is true for RISC processors, but the complaint was being
>made about the CISC implementation. My small (4 person) programming shop
>maintains our code for a number of platforms. For CISC implementations
>we usually tune critical sections in assembly and usually let the
>compiler worry about that for RISC implementations. If we can do that,
>I'm sure that a megabucks company can spare a few programmers for a
>project that would greatly enhance their products.

I agree totally. In addition for QD GX, they used fixed point math. No
current languages have built-in support for fixed point math, so a high
level implementation will not benefit fully from the integer speed of
fixed point.

Floating point is more suitable for high level languages and is probably
just as fast as fixed point on the PowerPC architecture.

Then again, floating point would have been a very bad idea on the 68K
machines.

It seems to me that the best solution would have been to write two versions:
first a floating point/high level language implementation to debug the
algorithms and then a fixed point/assembly language implementation to
make it run ok on the current Macs.

- -- 
  Juri Munkki					       Windsurf: fast sailing
 jmunkki@hut.fi					      Macintosh: fast software

+++++++++++++++++++++++++++

From: d88-jwa@dront.nada.kth.se (Jon Wtte)
Date: 4 Jan 93 11:26:10 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <1992Dec31.224923.15838@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes:

>>Well, concerning a PowerPC port it makes sense, because asm is no-no
>>or 'if-you-really-need-it' option on this platform.

>Uhhh.... why?

Because you don't know how the compiler will schedule instructions
and use condition code sets. Note the s. Computers today are not
what they used to be; what we see now is a more and more complex
interaction between compiler, libraries and hardware; you really
need machines to keep track of getting it all right!

If you would want to write a context-free assembly portion, you
would have to surround it by several (5 on each side?) NOP
instructions; and then would degrade the performance of that
asm{} by quite a bit...

Cheers,

						/ h+

- -- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --

 -- I don't fear death, it's dying that scares me.

+++++++++++++++++++++++++++

From: bhanafee@picasso.ads.com (Brian Hanafee)
Date: 4 Jan 93 22:44:31 GMT
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)


In article <1993Jan1.183451.22522@nntp.hut.fi> jmunkki@vipunen.hut.fi (Juri Munkki) writes:
>I agree totally. In addition for QD GX, they used fixed point math. No
>current languages have built-in support for fixed point math, so a high
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*Almost* no current languages.  Ada does (see section 3.5.9 of the Ada
LRM).  Though I still wouldn't recommend using Ada to write QD GX,
it's a feature that of Ada that I'd really like to see in some other
languages.  Note that this is in addition to, not in place of, integer
and floating types.  When fixed point types are the right thing, it's
much easier than using integers and trying to keep track of the binary
point yourself.  Let the compiler do all the work!

>level implementation will not benefit fully from the integer speed of
>fixed point.

- --
Brian Hanafee                         Advanced Decision Systems
bhanafee@ads.com                      1500 Plymouth Street
(415) 960-7300                        Mountain View, CA 94043-1230

---------------------------

End of C.S.M.P. Digest
**********************